IIRC, this test was moved to compile-fail due to instability in the order of suggestions (see #40775), so this will probably have to do be reverted, unless you want to fix the instability.

I'll fix the instability

Are the "did you mean" questions... rhetoric?
Is it ok to omit question marks in this context, linguistically?

The issue is that we have no idea whether the suggestion author wrote try or did you mean, so we can't generate a questionmark out of thin air. We could cover the common cases like did you mean, but have you tried won't get caught or any other textual changes

I think it's ok to add a heuristic catching "did you"/"have you" and appending the question mark.
All the messages are controlled by us after all, so they can always be tweaked if there are false positives/negatives.

(I'm assuming adding an extra argument to span_suggestion would be cumbersome, but it's a variant too.)

We could allow a placeholder in the message. So if you write did you mean {}? it will produce

did you mean `foobar`?

An in case it's not displayed inline, but as a help, the placeholder is replaced by "the following":

did you mean the following?

That would probably be the most convenient (I can live with a bit of home-grown formatting).

Ok. I implemented this, but the code complexity goes way up. I need to find the correct {}. I'll also need to allow {{ to escape opening brackets. I need to allow some way to specify a replacement like "the following", ....

How about my first variant suggested here?

add a new enum so the lint author can choose a message

enum SuggestionMsg {
    DidYouMean,
    Try,
    Custom {
        label: String, // msg to display as label
        help: String, // msg to display as help
    },
}

cc @nrc this touches on prepending help: before suggestions displayed as labels

I went through all suggestions' messages in rustc:

• 5 "did you mean {the following}"
• "try casting to a reference instead:"
• "try casting to a Box instead:"
• "possible candidates found in another module, you can import them into scope:"
• "did you mean to use the variant's enum"
• "try adding parentheses:"
• "try parenthesizing the first index"
• "try placing this code inside a block"
• "make this visible only to module {} with in:"
• really long message about to_owned
• "to access tuple elements, use"
• "to force the closure to take ownership of {} (and any other referenced variables), use the move keyword, as shown"
• "consider using a reference instead"

I don't see a good way to get all of these under one hat.

ISTM that the client should choose the punctuation here, which suggests that using {} is the best way. However, the extra complexity does seem a bit annoying. I think the current mix of template and free text is probably wrong - could we either allow totally free text or lock down the structure of the text more strictly (as an aside, I've never liked the "did you mean ..." phrasing, feels patronising, I'd prefer "you could try ...", but I don't care too much and this is a bit orthogonal.)

OK. I'll create a commit with the enum variant to see how it looks. Then we can reiterate.

I added some guidelines for suggestion messages. This way we can keep appending the suggestion at the end. I like this solution, because it's easy to read on the command line, requires little effort from suggestion authors and works well with non-label suggestions and json output.

I think it's better to keep these annotations.
UI and compile-fail tests are going to be unified and ERROR/WARN will be necessary again.

these look... funny to me now. I think it's just the juxtaposition of ? and :... can we end it with something like "did you mean to compare equality? Consider: x == x" instead?

Hm... those came in after a rebase. I'll create a new PR fixing up all suggestions that came in after I wrote the guidelines into the docs.